情境說明

初期

• 在我剛加入這個公司的初期，有三個老闆：公司總經理 A、總經理的接班人 B、部門主管 C，會議進行的形式大概是⋯⋯
• 與 部門老闆 C 在每週一早上會固定開會討論工作的進度
  • 開會所使用的投影片，由「PM」負責投影；投影片的製作，則是由負責不同專案的人，共編一份投影片
  • 每個人對於寫投影片的標準都不一定
    • 有時候老闆不想知道太多實作細節，畢竟如果大家都講很細的細節，那會議就開不完了
    • 有時候老闆又想知道，某某專案到底都卡在什麼環節
  • 每次開會的節奏，都是老闆掌握度高的案件，被追蹤的內容會比較少，對於比較菜的同事，比較難去理解他在做什麼，相較之下那些工作遇到瓶頸的，總是花很多時間被檢討而沒有解決問題
• 部門老闆 C 與 總經理 A 每週三固定的高層會議
  • 有時候高層對於某些議題發問時，當高層問太細的時候，就會臨時抓負責的專案經理或是工程師進去回答問題
  • 臨時抓進會議，倉促沒有準備進會議，通常都是心驚膽顫
  • 不過因為 總經理 A 是留學歸國，重視效率，不喜歡看投影片，通常問出答案就會放人
• 總經理接班人 B
  • 接班人因為大多時間都在海外，所以會議時間不固定
  • 管理的風格比較接近業務，關心的是包裝、行銷、銷量數字等
    
  • 然後這個 甘特圖 ... 哎，用 PowerPoint 畫甘特圖，畫的人痛苦，看的人也痛苦
• 三個老闆性格都不同，開會要準備要三個版本的投影片是很惱人的

導入看板流

• 因為上面列出的問題已經是陳年舊帳，所以在年初的部門會議中，決議先試用個 Asana，一直沿用到現在
• 使用看板的管理方式，是由 豐田汽車前副社長 大野耐一 所提出
• 對於專案進度的管理，有很多流派和工具，不逐一介紹
• 看板的精髓，從 Asana 的介紹 中列出 4 個核心原則 與 6 個實踐做法
  • 在核心原則中，不用大破大立，所以在導入的前期，團隊成員只需依序將自己手邊進行中的工作，寫成卡片即可開始
  • 導入看板，並不像 OKR 或是 Scrum 這種⋯⋯雖然我自己沒經歷過，但也聽說過。
    • 我聽聞有團隊在導引 Scrum 的時候，衝刺會議沒有掌握時間重點 、 Scrum Master 不清楚自己的角色、成員每天都要站會，最後都要硬擠硬掰些東西亂糊弄
    • 對於職場老油條們的巨大陣痛期，肯定是排斥的
  • OKR 那種做法，是假設每個人都有狼性，對於工作成員性質皆不同的情況下，是不太適合導入的
  • 因為看板成員中彼此是沒有特別制定馴獸師和動物的角色，所以有熱心有良知的前輩會更容易協作
• 對於 專案的管理，有很多流派和工具，不逐一介紹
• 這邊只關注可以 方便掌握工作進度 的工具、取得工作進度或狀態、並且拿來產生投影片

Asana API

• Asana 本身有分成免費和付費的，以下介紹的功能，免費使用者也可以使用
• 從 https://asana.com/guide/help/api/api 的說明得知，要先建立 PAT (Personal Access Token)
• 這邊假設你已經有在使用 Asana 了，也加入或創建組織了，點選網址 https://app.asana.com/0/my-apps
  
• 產生一個 Token 並取名寫個用途，日後好管理（清除權限）
  
• 從 測試頁面 中， Try API 時，放入剛剛產生的 Token 及對應參數
• 稍微試用一下，記錄拿資料的流程大致是 取得 Workspace、取得使用者、取得工作...